Inception (UP)
Inception Phase Most projects require a short initial steps in which the following questions are explored: What is the vision and business case for this project? Feasible? Buy and/or build? Rough unreliable range of cost: Is it 10K-100K or in the millions? Should we proceed or stop? Defining the vision and obtaining an order-of-magnitude (unreliable) estimate requires doing some requirements exploration. Do just enough investigation to form a rational, justifiable opinion of the overall purpose and feasibility of the potential new system, and decide if it is worthwhile to invest in deeper exploration (the elaboration phase). **The main problem solved**\\ Do the stakeholders have basic agreement on the vision of the project, and is it worth investing in serious investigation? Length of Inception The intent of inception is to establish some initial common vision for the objectives of the project, determine if it is feasible, and decide if it is worth some serious investigation in elaboration. If it has been decided beforehand that the project will definitely be done, and it is clearly feasible, the inception phase will be especially brief. It may include the first requirements workshop, planning for the first iteration, and then quickly moving forward to elaboration. Artifacts in Inception A key insight is that the artifacts are only partially completed in this phase, will be refined in later iterations, and should only be created if they add real practical value. Also, the investigation and artifact content should be light. The point of creating artifacts or models is not the document or diagram itself, but the thinking, analysis, and proactive readiness. For developing a rough high-level vision of the system scope, purpose, and risks, the Use-Case Model may list the names of most of the expected use cases and actors, but perhaps only describe 10% in detail. Note: Some programming work may occur in inception in order to create “proof of concept” prototypes, to clarify a few requirements with (typically) UI-oriented prototypes, and to do programming experiments for key “show stopper” technical questions. Note: Artifacts from previous projects can be partially reused on later ones. It is common to be many similarities in risk, project management, testing, and environment artifacts across projects. All UP projects should organize artifacts the same way, with the same names, for simplifying finding reusable artifacts from prior projects on new ones. List of common inception artifacts: * **Vision and Business Case:** Describes the high-level goals and constraints, the business case, and provides an executive summary. * **Use-Case Model:** Describes the functional requirements. During inception, the names of most use cases will be identified, and perhaps 10% of the use cases will be analyzed in detail. * **Supplementary Specification:** Describes other requirements, mostly non-functional. During inception, it is useful to have some idea of the key non-functional requirements that have will have a major impact on the architecture. * **Glossary:** Key domain terminology, and data dictionary. * **Risk List & Risk Management Plan:** Describes the risks (business, technical, resource, schedule) and ideas for their mitigation or response. * **Prototypes and proof-of-concepts:** To clarify the vision, and validate technical ideas. * **Iteration Plan:** Describes what to do in the first elaboration iteration. * **Phase Plan & Software Development Plan:** Low-precision guess for elaboration phase duration and effort. Tools, people, education, and other resources. * **Development Case:** A description of the customized UP steps and artifacts for this project. In the UP, one always customizes it for the project. UML During Inception Perhaps beyond simple UML use case diagrams, not much diagramming is warranted. There is more focus in inception on understanding the basic scope and 10% of the requirements, mostly in text forms. Most UML diagramming occur in elaboration. For example, the Use-Case Model may list the names of most of the expected use cases and actors, but perhaps only describe 10% of the use cases in detaildone in the service of developing a rough high-level vision of the system scope, purpose, and risks. Note that some programming work may occur in inception in order to create "proof of concept" prototypes, to clarify a few requirements via (typically) UI-oriented prototypes, and to do programming experiments for key "show stopper" technical questions. Category:Unified Process